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Abstract 

In  this  report,  we  propose  an  alternative  approach  to  behavioral  object  orientation,  especially 
well-suited  for  complexly  structured  systems.  The  data  wiU  be  modelled  as  complex  objects  to 
capture  the  structured  and  interrelated  properties  of  the  system.  The  dynamic  laws  of  system's 
behavior  will  be  stated  as  transformation  rules  on  the  complex  object.  Complex  objects  together 
with  transformation  rules  are  integrated  into  a  coherent  concept  of  a  Complex  System.  Complex 
Systems  can  be  used  for  prediction  of  the  future  by  asking  futuristic  queries  about  future  states  of 
complex  objects.  In  general.  Complex  Systems  do  not  provide  unique  answers  to  futuristic  queries 
because  of  inherent  non-determinism.  Therefore,  an  optimal  control  problem  is  formulated  that 
finds  optimal  behavior  to  satisfy  user-defined  goals.  Consequently,  such  goals  are  converted  into 
additional  system  constraints,  thus  reducing  non-determinism.  A  small  but  instructive  example  of 
a  Flexible  Manufacturing  System  is  used  throughout  the  report. 


1      Introduction 

Description  of  any  system  usually  consists  of  two  components.  The  first  component  defines  struc- 
tural properties  of  the  system.  There  have  been  many  data  models  proposed  in  the  past  that 
describe  these  properties  in  terms  of  highly  structured  entities;  [29,47,14,7,6]  are  a  few  examples. 
This  approach  is  called  structural  object-orientation. 

The  second  component  defines  a  set  of  processes  that  can  take  place  in  the  system.  Traditionally, 
these  processes  are  defined  by  taking  composition  of  operations  drawn  from  a  set  of  elementary 
operations.  In  particular,  the  object-oriented  approach  to  defining  these  operations  has  become 
very  popular  in  the  last  few  years  [4,2,3,28]. 

There  have  been  recent  attempts  to  combine  these  two  methods  into  one  integrated  approach 
[25]  called  behavioral  object-orientation  [16].  In  this  approach,  the  processes  are  described  by  user- 
defined  type-specific  operations  on  complexly  structured  objects,  and  the  operations  are  grouped 
into  abstract  data  types. 

In  this  report,  we  propose  a  different  approach  to  behavioral  object-orientation.  A  state  of 
the  system  will  be  described  in  terms  of  complex  objects  (CO)  [29,6].  However,  the  processes 
will  be  defined  with  a  set  of  rules,  called  transformation  rules,  that  will  describe  local  changes 
to  the  system.  Given  the  initial  state  of  the  system  and  a  set  of  transformation  rules,  the  set  of 
possible  trajectories  of  the  system  can  be  found  by  repeatedly  applying  transformation  rules  to  the 
CO.  Complex  objects  together  with  transformation  rules  will  be  integrated  into  the  concept  of  a 
Complex  System  (CS).  This  approach  can  also  be  called  behavioral  object-orientation  because  it 
defines  behavior  of  a  system,  and  because  this  behavior  is  expressed  in  terms  of  changes  to  the 
objects. 

Complex  System  formalism  can  be  used  for  prediction  and  control  of  the  future.  By  prediction 
we  assume  the  ability  to  ask  futuristic  queries,  i.e.  queries  about  the  potential  future  states  of  the 
database.  By  control  we  assume  the  ability  to  make  judicious  (optimal)  decisions  in  order  to  reach 
certain  future  states  that  satisfy  user-defined  goals. 

To  predict  the  future,  one  has  to  define  the  language  in  which  the  predictions  will  be  expressed, 
i.e.  a  futuristic  query  language.  One  also  has  to  provide  practical  query  processing  mechanisms 
for  this  language.  We  will  address  these  issues  and  will  also  present  an  efficient  query  processing 
technique  to  answer  a  subclass  of  futuristic  queries. 

The  accuracy  of  future  predictions  depends  on  the  degree  of  non- determinism  of  the  system.  A 
vending  machine  is  an  example  of  a  causal  system.  Once  coins  are  inserted  in  it,  one  can  predict 
the  sequence  of  events  that  follow.  In  contrast,  a  chess  game  constitutes  an  example  of  a  non- 
deterministic  system:  we  cannot  predict  perfectly  the  position  on  the  board  after  several  moves. 


In  general,  the  problem  of  non-determinism  must  be  addressed  to  predict  the  future. 

One  way  to  restrict  non-determinism  and,  consequently,  make  more  accurate  predictions  about 
future  states  of  a  system,  is  to  understand  its  objectives.  As  will  be  described  in  this  report,  there  is 
a  way  to  convert  objectives  into  additional  constraints,  thus  reducing  non-determinism.  To  achieve 
this,  techniques  from  optimal  control  theory  [8]  and  operations  research  will  be  utilized. 

One  has  to  examine  the  class  of  applications  for  which  the  complex  system  model  is  especially 
well-suited.  Such  applications  are  characterized  by  hierarchically  structured  and  interrelated  data 
and  exhibit  causaJ  and  goal  oriented  behavior.  We  believe  that  the  "advanced"  systems,  e.g. 
engineering,  industrial  and  organizational  (including  office  information),  fall  into  this  category. 
These  are  the  types  of  systems  we  axe  interested  in. 

Complex  Systems  are  related  to  various  formalisms  for  modelling  behavior  in  databases  and  in 
computer  science  in  general.  We  will  discuss  these  connections  in  Section  2.3.  The  most  important 
of  them  are  analytical  modelling  and  expert  systems,  especially,  production  systems  [56],  in  AI. 
Because  of  their  importance,  we  want  to  discuss  them  now. 

Management  science  is  a  discipline  which  also  deals  with  modeling  and  analysis  of  large  indus- 
trial, economic  and  organizational  systems.  It  utilizes  classical  tools  of  mathematical  modeling, 
such  as  differential  and  recurrence  equations,  linear  algebra  and  optimization  theory,  to  describe, 
analyze  and  predict  behavior  of  such  systems.  However,  these  analytical  methods  are  inadequate 
for  the  proper  description  of  complexly  structured  systems.  Therefore,  we  propose  Complex  Sys- 
tems as  a  computational  counterpart  to  the  analytical  modeling.  We  believe  that  CS  will  be  able 
to  predict  certain  aspects  of  behavior  of  large  systems  better  than  the  existing  analytical  tools. 

Complex  Systems  can  also  be  viewed  as  an  extension  of  production  systems.  ClassicaJ  pro- 
duction systems  [56]  are  less  suitable  for  the  purpose  of  predicting  and  controlling  the  behavior 
of  complex  engineering,  industrial  and  organizational  systems.  Even  though  they  have  the  same 
expressive  power  as  Complex  Systems  (the  power  of  the  Turing  Machine),  it  would  taJce  more  en- 
coding [31]  to  model  the  same  future-related  application  with  a  production  system  because  of  the 
following  reasons.  First  of  all,  production  system  memory  does  not  support  the  complete  model 
of  the  complex  object,  although  it  has  some  of  its  features.  Secondly,  production  systems  do  not 
define  time  explicitly;  thus,  they  require  encoding  to  simulate  time.  Therefore,  production  systems 
cannot  model  concurrency  issues  adequately,  including  the  race  problem  [49,  pp.  51-53].  Finally, 
production  systems  do  not  support  non-determinism  and  the  mechanisms  to  control  it.  There- 
fore, Complex  System  can  be  viewed  as  an  extension  of  production  system  that  supports  complex 
objects,  time  and  non-determinism. 

We  are  making  the  foUowing  contributions  in  this  report.  First,  we  define  Complex  Systems  as 


an  extension  of  production  systems  to  accommodate  structured  data,  time  and  non-determinism. 
In  particular,  we  believe  that  these  extensions  will  allow  us  to  model  systems  currently  being 
described  by  differential  and  recurrence  equations  such  as  engineering,  industrial  and  economic 
systems.  Secondly,  we  introduce  futuristic  query  language  to  predict  the  future,  and  propose 
efficient  query  processing  strategy,  called  Propagation  Algorithm.  Finally,  we  propose  the  way  to 
restrict  non-determinism  and  achieve  optimal  performance  of  a  system  by  stating  an  optimization 
problem  and  converting  system  goals  into  additional  constraints  on  its  future  behavior. 

We  will  define  the  concept  of  a  Complex  System  in  the  next  section.  Section  3  will  introduce 
a  futuristic  query  language  and  a  query  processing  algorithm.  Section  4  defines  the  optimization 
problem. 

2      Complex  System 

Complex  System  will  consist  of  two  components.  The  first  component,  Complex  Object,  defines 
structural  properties  of  the  data  comprising  the  system.  The  second  component  defines  rules 
governing  temporal  behavior  of  the  system. 

2.1      Complex  Objects 

We  represent  the  state  of  the  complex  system  with  a  complex  object  (CO).  Various  researchers 
have  different  ideas  what  formal  counterpart  for  an  intuitive  concept  of  the  complex  object  should 
be.  The  term  was  originally  coined  by  Lorie  and  Plouffe  [29].  Different  approaches  to  modeling 
CO  are  represented  by  XSQL  [29],  molecular  objects  [7],  NF^  forms  [14,37,55],  POSTGRES  [47]. 

Our  definition  of  complex  objects  combines  numerous  other  approaches.  Space  limitations  do 
not  permit  us  to  examine  every  single  detail  of  this  concept;  refer  to  [51]  for  details. 

A  Complex  Object  (CO)  is  a  triple  (CE,  R,  IC).  CE  is  a  complex  entity,  R  is  a  set  of 
relationships  and  IC  is  a  set  of  integrity  constraints.  We  elaborate  these  three  concepts  now. 

The  set  of  complex  entities  is  defined  recursively: 

1.  An  attribute  (a  labelled  domain)  defines  a  class  of  complex  entities,  called  atomic  or  elemen- 
tary entities.  For  example.  Name,  Salary,  Position  are  elementary  entities. 

2.  If  Oi, 02,..  •  ,0n  are  classes  of  complex  entities,  then  the  Cartesian  product  Oi  XO2X. .  .xO„ 
is  also  a  class  of  complex  entities. 

3.  If  O  is  a  class  of  complex  entities  then  the  Power  set  V{0)  is  also  a  class  of  complex  entities. 

4.  If  0i,02,...,0n  are  mutually  exclusive  classes  of  complex  entities  (  O,  D  Oj  =  0  )  then 
Ur=i  Oi  is  also  a  class  of  complex  entities. 


This  definition  of  a  complex  entity  is  a  slight  modification  of  the  concept  of  complex  object 

from  [6]. 

A  tree-structured  schema  is  associated  with  each  class  of  complex  entities.  See  [52,24]  for  a 
rigorous  alternative  definition  of  a  concept  of  complex  entity  in  terms  of  this  schema.  A  subtree  of 
this  schema  is  called  a  subschema. 

A  subentity  of  a  given  complex  entity  is  defined  recursively.  An  attribute  of  a  tuple  entity  is  a 
subentity  of  that  tuple.  A  element  of  a  given  set  entity  is  a  subentity  of  that  set.  Also,  subentity 
relationship  is  closed  under  transitivity.  This  definition  is  the  same  as  the  definition  of  "part-oP 
relationship  in  [6].  For  each  subschema,  there  is  a  class  of  subentities  of  the  given  complex  entity, 
associated  with  that  subschema. 

Note  that  the  definition  of  a  complex  entity  is  based  on  classification,  aggregation,  generalization 
and  association  abstractions  [9,50,43,22]  and  is  similar  to  the  notions  of  domain  of  a  format  [24], 
structural  set  [52],  an  object  [9],  a  complex  object  [6]  and  AND/OR  graph  [22,23]  . 

R  is  a  set  of  relationships  among  subentities  of  CE.  A  relationship  R  G  R,  defined  on  classes  of 
subentities  Ei,E2,...,En  of  a  complex  entity  CE,  is  a  subset  of  Ei  x  E2  x  . . .  x  En  such  that  no 
Ei  and  Ej  are  on  the  same  hierarchical  path.  R  is  associated  with  the  class  of  subentities  being  the 
least  common  ancestor  of  {Ei}i=\ „•  The  concept  of  a  relationship  is  borrowed  from  the  Entity- 
Relationship  model  [13].  However,  unlike  that  model,  we  do  not  distinguish  between  entities  and 
attributes.  Both  are  entities  in  our  model. 

We  introduce  the  concept  of  relationship  because  the  transformation  rules  we  define  later  on  will 
be  naturally  expressed  in  terms  of  relationships.  In  other  words,  it  would  require  more  encoding 
to  express  dynamic  behavior  of  the  system  without  the  notion  of  relationship. 

A  set  of  integrity  constraints  (IC)  is  specified  for  the  object  or  its  subobjects.  Integrity  con- 
straints are  defined  as  a  set  of  well-formed  formulas  (wfT)  with  additional  restrictions  imposed  on 
them,  called  range  restrictions  [33].  In  section  2.2,  preconditions  of  a  transformation  rule  wiU  also 
be  expressed  as  wflfs.  Therefore,  we  postpone  formal  treatment  of  the  subject  until  then.  Some 
integrity  constraints  can  be  found  in  Example  1. 

Let  CO  =  {  CE,  R,  IC  }  be  a  complex  object.  A  subentity  of  CE  together  with  relationships 
from  R  and  integrity  constraints  from  IC,  "restricted"  to  that  subentity,  is  called  a  subobject  of 
the  given  CO. 

Several  models  of  complex  objects  are  similar  to  the  one  presented  above  such  as  DODM  model 
of  the  DAMOKLES  project  [17],  SEED  [20]  and  SAM*  [48]  models. 

Example  1.  Consider  a  Flexible  Manufacturing  System  (FMS)  [40,21].  The  system  consists  of 
a  number  of  workstations,  called  cells,  eax;h  cell  being  responsible  for  performing  a  certain  assembly 


operation.  In  our  example,  FMS  manufactures  two  kinds  of  chairs:  a  side  chair  and  an  armchair 
(Fig.  1<).  Also,  there  are  vehicles,  called  Automatic  Guidance  Vehicles  (AGVs),  moving  from  one 
cell  to  another,  carrying  incomplete  assemblies  of  chairs.  They  move  along  the  routes  determined 
by  a  central  computerized  controller.  Moreover,  there  is  a  load/unload  station  from  which  an  AGV 
starts  its  route  with  the  initial  part  of  a  chair  loaded  on  it.  An  AGV  returns  to  the  load/unload 
station  with  the  assembled  product. 

The  structure  of  FMS  is  shown  in  Fig.  lb.  The  tree  diagram  defines  CE  part  of  the  complex 
object  FMS.  Note  that  the  branches  and  dots  below  AGV,  cell,  and  load/unload  station  in  Fig. 
lb  indicate  that  they  are  complex  objects  and  consist  of  subobjects  which  are  not  shown  here  for 
the  sake  of  conciseness.  We  did  not  represent  relationships  between  subentities  graphically  in  order 
not  to  clutter  the  diagram.  Relationships  R  and  the  integrity  constraints  IC  are  shown  below  the 
diagram  in  Fig.  lb.  Fig.  Ic  shows  the  syntactic  definition  of  the  complex  object  written  in  a  C-like 
DDL.  In  general,  the  relationships  are  associated  with  the  least  common  ancestor  of  the  subobjects 
participating  in  this  relationship;  in  this  simple  example,  it  turns  out  to  be  the  root. 

We  can  observe  the  following  facts  about  syntactic  representation  of  complex  objects.  Aggre- 
gation is  expressed  as  the  C-like  structure.  Association  is  represented  with  the  "set_of  or  "listjof" 
syntax,  the  latter  being  used  for  ordered  sets.  Generalization  is  expressed  in  terms  of  C-like  unions. 
Notice  the  use  of  vectors  (for  part_3). 

■ 

2.2      Dynamic  Behavior  of  Complex  Objects 

We  represent  behavioral  aspects  of  complex  objects  by  transformation  rules.  A  transformation 
rule  is  a  triple 

(precondition,  {actions},  time) 

where  precondition  is  an  assertion  about  the  current  state  of  the  complex  object,  {actions}  is  a  set 
of  alternative  actions  that  can  be  triggered  by  preconditions,  "time"  is  the  time  it  takes  to  complete 
the  actions. 

The  concept  of  precondition  is  based  on  the  many-sorted  first  order  logic  [19,  §4.3]  ^.  However, 
we  wiU  add  some  extensions  to  many-sorted  logic  to  accommodate  CO  model.  These  extensions 
are  purely  syntactic  because  their  semantics  will  be  defined  in  terms  of  semantics  of  equivalent 
formulas  in  the  original  many-sorted  logic. 

For  a  given  CO,  associate  a  sort  with  each  node  of  the  tree  of  the  schema  of  the  CO.  The 
alphabet  of  a  many-sorted  logic  contains  constants,  variables,  function  symbols,  predicate  symbols 


'  it  is  ako  called  typed  logic. 


and  quantifiers,  each  of  them  being  associated  with  some  sort.  Function  symbols  will  be  restricted 
to  standard  arithmetic  functions.  The  predicates  consist  of  the  relationships  of  the  CO,  comparison 
relations  (=,<,<)  and  set  membership  (e). 

The  set  of  terms  of  sort  r  is  defined  as  follows:  1)  a  constant  or  a  variable  of  sort  r  is  a  term  of 
that  sort;  2)  if  Xi  is  a  variable  of  sort  r,  for  t  =  1, . . .  ,n  and  r,,r,+i  are  the  sorts  corresponding  to 
the  hierarchically  adjacent  nodes  in  the  tree  then  ii.i2-  •  •  •  .in  is  a  term  of  sort  t„;  we  will  call  it  a 
path;  3)  if  /  :  Ti  X  . . .  X  r„  ->  T  is  an  n-ary  function  and  U  is  a  term  of  sort  r^  then  f{ti ,  ^2,  •  •  •  >  ^n) 
is  a  term  of  sort  t.  This  definition  of  a  term  differs  from  the  standard  one  [19]  in  item  2  (concept 
of  a  path). 

A  many-sorted  atomic  formvdais  defined  as  P(ti,  ^2,  •  •  •  <n),  where  P  is  one  of  the  n-ary  predicates 
Ti  X  . . .  X  r„  — >  {t,  /}  defined  above,  and  t,  is  a  term  of  sort  r^.  A  many-sorted  well-formed  formula 
is  defined  as  a  closure  of  atomic  formulas  under  the  operations  of  "and",  "or",  "not"  and  sorted 
existential  and  universal  quantifications. 

A  precondition  is  a  conjunctive  clause  in  the  defined  language.  This  definition  of  precondition 
is  not  restrictive  because  any  well-formed  formiila  can  be  converted  to  the  disjunctive  normal  form; 
then  the  transformation  rule  with  a  well-formed  formula  as  a  precondition  can  be  split  into  several 
transformation  rules,  each  having  conjunctive  clause  as  its  precondition.  Note  that  this  argument 
is  very  similar  to  the  one  used  for  explaining  how  any  logical  program  can  be  converted  to  an 
equivalent  normal  form  program  and,  specifically,  to  a  PROLOG  program  [27,  Ch.  4]. 

We  associate  a  formula  without  paths  with  each  formula  containing  paths  as  follows.  A  path 
ii.xa.  •  •  •  -Xn,  where  i,  hzis  sort  Ti,  will  be  replaced  by  !„,  and  the  following  sentence  will  be  added 
to  the  formida: 

A"=2(3T.iZ,i)...(3T.,,Zifc.)((2.i,...2.it.,a;.)  e  Xi-i) 

where  node  of  sort  r^-i  hais  nodes  of  sort  th  ,  r,2 , . . .  r,fc, ,  r,  as  children  in  the  CO  schema  and  2,j  is 
a  variable  of  sort  r,j.  Therefore,  paths  can  be  thought  of  as  macrvs  in  the  standard  many-sorted 
first  order  theory.  Since  the  formulas  with  paths  can  be  converted  into  formulas  without  paths  in 
a  first  order  theory,  the  introduced  language  with  paths  is  really  a  first  order  language. 

Example  2.     The  precondition  "Cell  manufacturer  is  GE  for  the  cell  type  C23"  or 

FMS.cell_type.manufacturer  =  'GE'  and  cell_type.id  =  'C23' 

is  replaced  by  the  following  formula  without  paths: 

manufacturer  =  'GE'  A  id  =  'C23'  A  (3too/»^i)(3ceH-^2)(3c/iat>^3)(3/iGvZ4)(3ioo<i/unioa<f^5) 
{{zi,Z2.,manufactuTer,id)  ^  celljype)  A   {z3,Z4,zs,cellJyp€)  £  FMS) 


The  second  parameter  in  the  transformation  rule  is  the  set  of  actions.  Each  action  consists  of 
a  sequence  of  elementary  actions.  We  propose  the  following  three  elementary  actions: 

•  INSERT.  It  consists  of  2  kinds  of  operations.  The  format  of  the  first  one  is  INSERT(0l,02,..., 
On,  R),  where  R  is  a  relationship  of  the  given  CO  with  n  attributes,  and  Oi  is  a  complex  ob- 
ject, corresponding  to  the  i-th  attribute  of  R.  This  operation  inserts  tuple  (01,02,..., On)  into 
relationship  R.  The  format  of  the  second  operation  is  INSERT(0_type,0  Jnst,P_type,P  Jnst), 
where  P_type  and  O.type  are  subschemas  of  the  CO  schema  such  that  the  root  node  of  the 
former  is  the  parent  of  the  root  node  of  the  latter;  and  0  Jnst  and  O  Jnst  are  complex  sub- 
objects  corresponding  to  that  subschemas.  The  second  operation  inserts  instance  0  Jnst  as  a 
child  of  P  Jnst.  Aliases  ENS_REL  and  INS_PAR  will  be  used  for  these  two  kinds  of  operations 
respectively. 

•  DELETE.  It  also  consists  of  2  kinds  of  operations.  DELETE(0l,02,...,0n,R)  deletes  tuple 
(01,02,..., On)  from  relationship  R.  DELETE(OJnst,0_type,PJnst,  P.type)  deletes  object 
instance  O  Jnst  of  type  0_type  who  is  a  child  of  P  Jnst  of  type  P_type.  Aliases  DEL_REL  and 
DEL_PAR  will  be  used  for  these  two  kinds  of  operations  respectively. 

•  UPDATE  operator.  Its  format  is  "path  =  /(path)",  where  /  is  a  function  operating  on  the 
leaf  variable  of  the  path,  e.g.  Chair.status  =  Chair.status  -f  1.  We  associate  a  set  of  functions 
with  each  elementary  object.  /  belongs  to  the  set  of  functions  associated  with  the  leaf  object 
of  "path",  e.g.  "-)-"  is  associated  with  "status"  in  the  previous  example. 

We  also  define  a  macro  MOVE  on  binary  relations  only.  Its  format  is  MOVE(Ol,  R,  02, 
Q,  03),  and  it  is  equivalent  to  the  sequence  "DEL_REL(0l,02,R);  INS_REL(02,03,Q)".  The 
comprehensive  example  in  this  section  will  illustrate  the  usage  of  actions. 

Observe,  that  a  precondition  can  lead  to  a  number  of  alternative  actions.  Therefore,  transfor- 
mation rules  are  non-deterministic  in  general.  However,  we  will  also  consider  deterministic  systems 
as  a  special  case  when  only  one  action  is  permitted  in  a  transformation  rule. 

One  might  consider  stochastic  behavior  too.  Stochastic  behavior  differs  from  non-deterministic 
one  because  we  can  make  choices  in  case  of  non-determinism,  whereas  the  system  is  moved  into 
one  of  the  available  states  according  to  some  probability  distribution  in  the  stochastic  case.  For 
example,  compare  a  non-deterministic  rule  "If  a  patient  is  admitted  to  the  hospital,  he  will  be 
assigned  to  any  available  room"  with  a  stochastic  one  "If  an  operation  is  performed  on  a  patient, 
then  with  .6  probability  he  will  live  and  with  .4  probability  he  will  die".  We  do  not  consider 
stochastic  rules  in  this  report. 


Time  is  the  third  parameter  in  a  transformation  riile.  It  is  a  function  <  :  ri  x  . . .  x  r„  — »^  JV, 
where  r^  is  the  sort  of  some  variable  that  appears  in  the  precondition  of  the  transformation  rule, 
and  N  is  the  set  of  natural  numbers.  This  parameter  computes  time  it  takes  for  the  actions  to  be 
performed,  given  that  preconditions  are  true.  Observe  that  time  is  the  same  for  all  the  elementary 
actions  in  the  transformation  rule.  This  means  that  the  elementary  actions  of  a  rule  are  atomic: 
aU  of  them  are  done  together  as  a  unit.  We  consider  only  a  discrete  model  of  time.  For  example, 
time  can  be  defined  by  the  system  clock. 

To  simplify  exposition,  we  assumed  that  actions  depend  only  on  the  current  state  of  the  system. 
We  can  use  some  standard  encoding  techniques  to  enforce  this  rule  if  some  actions  depend  on  previ- 
ous states  too.  Alternatively,  we  can  extend  the  notion  of  the  transformation  rule  to  accommodate 
previous  states  as  well. 

Example  3.  We  return  to  the  FMS  example  introduced  in  the  previous  section.  We  present 
transformation  rules,  describing  the  behavior  of  FMS.  We  assume  that  the  functions  PART_TYPE 
and  PART  are  defined  already. 

Rl:  If  AGV  is  docked  at  a  cell  with  the  chair  on  it  and  the  chair  has  not  been  assembled  yet,  then 
move  AGV  to  one  of  the  next  cells. 

precondition:  D1(AGV,  cell_type.cell)  and  Ll(chair,AGV)  and 
M(chair.status,  cell.type')  and  not  FINISHED(chair) 
action:  MOVE(cell,Dl,AGV,Dl,celLtype'.cell') 
time:  tl(AGV,ceU,cell') 

where  FINISHED  is  defined  as 

FINISHED(chair)  =  (chair.type  =  'side'  =>  chair.status  >  4)  and  (chair.type  =  'armjchair' 
=>  chair.status  >  6) 

R2:  If  AGV  is  docked  at  appropriate  cell  (which  can  assemble  the  next  part)  with  the  chair  on  it 
and  no  other  chair  is  in  that  cell,  then  transfer  the  chair  from  the  AGV  to  the  cell. 

precondition:  Ll(chair,AGV)  and  Dl(AGV,cell_type.cell)  and  M(chair.status,celLtype)  and 

not  L2(chair',cell) 

action:  M0VE(AGV,Ll,chair,L2,cell) 

time:  t2(AGV,cell_type) 

R3:  If  a  chair  is  at  the  cell  and  it  has  not  been  processed  yet  then  attach  appropriate  parts  to  it 
and  update  its  status. 


precondition:  L2(chair,celLtype.cell)  and  M(chair.status,  cell_type) 
action:  INSERT(PART_TYPE(chair.status),PART(chair.status),CHAIR,chair); 
chair.status=chair.statiis+ 1 
time:  t3(chair.status,celLtype) 

R4:  If  an  operation  on  a  chair  is  finished  by  the  cell  and  an  AGV  is  docked  at  the  cell  then  transfer 
the  chair  to  the  AGV.  ^ 

precondition:  not  M(chair.status,  cell-type)  and  D1(AGV,  cell_type.cell)  and 

L2(chair,celLtype.ceU) 

action:  M0VE(ceU,L2,chair,Ll,AGV) 

time:  t4(AGV,celLtype) 

R5:  If  AGV  is  docked  at  a  cell  with  the  chair  on  it  and  the  chair  has  been  assembled,  then  move 
AGV  to  the  load/unload  station  if  there  is  no  AGV  docked  at  the  station. 

precondition:  D1(AGV,  celLtype.cell)  and  Ll(chair,AGV)  and  FENISHED(chair)  and  not 

D2(AGV'4oad.unload) 

action:  M0VE(cell,Dl,AGV,D2,load.unload) 

time:  t5(AGV,cell,load_unload) 

R6:  If  an  AGV  is  docked  at  the  load.unload  station  with  a  chair  on  it  and  one  of  the  initial  cells 
has  no  vehicles  docked  at  it,  then  move  the  AGV  from  the  load.unload  station  to  it. 

precondition:  D2(AGV,load_unload)  and  Ll(chair,AGV)  and  chair.status  =  1  and 
M(l,cell.type)  and  not  Dl(AGV,ceU_type.cell) 
action:  M0VE(load_unload,D2,AGV,Dl,cell_type.cell) 
time:  t5(AGV,celI,load_unload) 

R7:  If  an  AGV  is  docked  at  the  load.unload  station  with  an  assembled  chair  on  it,  then  remove 
the  chair  from  the  FMS  system. 

precondition:  D2(AGV,load.unload)  and  Ll(chair,AGV)  and  FINISHED(chair) 
action:  DELETE(chair,AGV,Ll);  DELETE(chair,CHAIR,FMS,FMS_TYPE) 
time:  0 

R8:  If  an  empty  AGV  is  docked  at  the  load.unload  station  then  decide  non-deterministically  what 
kind  of  chair  to  produce  next;  create  that  chair  and  load  it  on  the  AGV. 


To  make  the  example  simple,  we  do  not  assume  that  an  AGV  must  be  empty  to  accept  a  chair. 


precondition:  D2(AGV,load_uiiload)  and  not  Ll(chair',AGV) 

action:  INSERT(chair,CHAIR,FMS,FMS_TYPE);  chair.type  =  "side"  or  "armjchair"; 

INSERT(part_l,PART,chair,CHAIR);  INSERT(chair,AGV,Ll) 

time:  0 

Observe  the  following  points  in  this  example.  First,  the  action  MOVE  in  Rl  is  non-deterministic 
because  an  AGV  can  be  moved  to  any  matching  ceU.  Second,  note  how  paths  are  used  in  precon- 
ditions, e.g.  "chair.status",  "cell.type.cell".  Third,  note  that  several  operators  appear  in  actions 
of  rules  R3  and  R8.  Fourth,  INSERT  in  R3  is  the  parent/child  insertion  operator:  it  inserts  an 
appropriate  part  into  the  chair.  Finally,  we  assumed  that  there  is  an  unlimited  supply  of  chair 
parts,  and  the  parts  are  supplied  as  soon  as  they  are  requested.  Usually,  parts  are  exogenous  to 
the  system  and  are  considered  as  its  inputs.  Therefore,  we  assume  that  the  FMS  system  has  no 
external  inputs. 

■ 

We  have  considered  a  complete  example  of  a  Flexible  Manufacturing  System.  However,  only 
the  partial  example,  consisting  of  the  rules  Rl  -  R4,  will  be  considered  in  the  sequel  for  the  sake 
of  simplicity. 

Definition.  A  Complex  System  is  defined  as  a  pair  (CO,  TR),  where  CO  is  a  complex  object 
and  TR  are  the  transformation  rules  defined  on  it. 

We  would  like  to  emphasize  the  following  advantages  of  Complex  Systems.  First,  CS  allows 
description  of  "structurally  rich"  applications,  e.g.  engineering,  in  a  natural  way  because  of  the 
underlying  CO  model.  Secondly,  CS  allows  description  of  behavioral  properties  of  hierarchically 
structured  interrelated  objects  in  a  natural  way  because  transformation  rules  support  the  concepts 
of  a  hierarchical  path  and  relationships  between  subobjects.  We  believe  that  CS  wiU  require  fewer 
transformation  rules  to  describe  most  of  the  complexly  structured  applications  then  the  classical 
production  systems,  e.g.  0PS5.  Thirdly,  CS  captures  non-deterministic  behavior.  Additionally, 
time  is  explicitly  introduced  in  CS;  therefore  behavior  of  various  subobjects  is  synchronized  in  a 
natural  way.  Finally,  transformation  rules  can  be  partitioned  into  "higher  level"  and  "lower  level" 
rules,  each  group  of  rules  being  associated  with  a  certain  level  in  the  CO  hierarchy.  For  example, 
the  rules  describing  behavior  of  a  cell,  are  associated  with  that  cell  and  are  "invisible"  outside  the 
cell.  Behaviorally  object-oriented  systems  enjoy  that  property  also  [25]. 

2.3     How  Complex  System  Model  is  Related  to  Other  Formalisms 

As  was  stated  before,  we  believe  that  Complex  Systems  are  well  suited  for  modelling  large  and 
complexly  structured  systems.  Some  of  these  systems,  like  FMS,  are  currently  being  modelled  by 
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various  analytical  tools,  including  operation  research  methods.  We  believe  that  CS  will  be  able  to 
describe  certain  aspects  of  behavior  of  these  systems  better  than  the  analytical  tools. 

This  belief  is  partially  bcised  on  the  observation  that  there  are  similarities  between  Complex 
Systems  and  systems  of  differential  and  recurrence  equations.  In  both  cases,  dynamic  properties 
of  a  system  are  described  as  local  changes  to  the  current  state  of  the  system.  These  changes  are 
expressed  in  terms  of  a  small  number  of  interrelated  variables.  Also,  system  behavior  is  defined 
implicitly  by  the  system  of  equations  or  transformation  rtiles:  the  future  behavior  of  the  system  is 
"hidden"  in  these  equations. 

However,  there  are  also  important  differences  between  Complex  Systems  and  differential  and 
recurrence  equations.  First,  the  system  state  is  usually  defined  as  a  vector  of  numeric  variables  in  the 
latter  case,  and  as  a  complex  object  in  the  former  one.  Secondly,  in  contrast  to  Complex  Systems, 
differential  equations  work  mostly  with  numeric  data.  Finally,  Complex  Systems  may  be  non- 
deterministic,  whereas  differentia]  equations  can  describe  only  causal  and  stochastic  systems.  These 
distinctions  make  differential  and  recurrence  equations  less  applicable  for  an  adequate  description 
of  advanced  industrial,  economic  and  organizational  systems. 

As  was  stated  in  the  introduction,  there  are  also  similarities  between  complex  systems  and 
production  systems.  Both  of  them  support  the  notions  of  state  (working  memory),  transformation 
rules  (production  memory),  actions  and  rule  interpreter  [56].  However,  Complex  Systems  support 
complex  object  model,  time  and  non-determinism. 

Behavior  can  also  be  modeled  using  operational  object-orientation  [4,2,3,28].  If  the  state  of 
the  system  is  also  defined  as  a  complex  object,  then  [16]  defines  this  combined  approach  as  behav- 
ioral oh  ject-onentation.  E?D^  [25]  and  SHM-|-  [9]  are  examples  of  behavioral  object-orientation. 
However,  we  believe  that  Complex  Systems  formalism  can  be  considered  as  an  alternative  type  of 
behavioral  object-orientation.  First,  it  is  based  on  the  structurally  object-oriented  model  of  com- 
plex objects.  Secondly,  behavior  is  expressed  in  terms  of  movements,  insertions  and  deletions  of 
objects. 

Because  of  space  limitation,  we  will  not  explore  when  behavior  is  better  expressed  in  terms 
of  transformation  rules  and  when  in  terms  of  operations  (including  object-oriented  programming). 
However,  we  want  to  point  out  that  this  discussion  is  related  to  the  analysis  when  logic  programming 
is  better  than  classical  procedural  programming  and  vice  versa.  We  believe  that  CS  formalism 
should  work  well  in  the  areas  where  systems  behavior  is  currently  defined  in  terms  of  differential 
and  recurrence  equations  such  as  engineering  and  industrial  applications. 

There  are  many  proposed  Information  Systems  design  methodologies  that  also  model  behavioral 
properties  of  applications  [36,35,34,53].    These  methodologies  define  various  kinds  of  high  level 
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specifications  of  information  systems.  Static  properties  of  these  specifications  are  mapped  into 
some  data  model  and  dynamic  properties  into  some  programming  language  (either  procedural  or 
object-oriented)  when  they  are  implemented  in  software.  It  would  be  interesting  to  analyze  how 
these  design  methodologies  can  be  mapped  into  complex  systems. 

RUBIS  [26]  is  a  recent  attempt  to  support  some  of  the  Information  Systems  design  methodologies 
directly  in  software.  It  can  also  be  considered  as  an  extended  relational  model  that  supports 
behavioral  concepts  such  as  event,  operation,  event  recognition,  operation  triggering  and  time 
handling.  The  main  behavioral  modelling  primitives  are  events  and  operations.  Events  trigger 
operations,  which  in  turn  result  in  new  events.  Observe  that  CS  approach  to  behavioral  modelling 
is  based  on  a  different  set  of  behavioral  concepts,  i.e.  transformation  rules,  rule  matching  and 
simulation  process . 

Triggers  [5,46]  and  alerters  [11]  are  other  concepts  related  to  Complex  Systems.  As  in  trans- 
formation rules,  triggers  are  also  based  on  preconditions  and  actions;  actions  are  "fired"  when 
preconditions  are  met.  However,  triggers  execute  actions  instantly,  and  the  process  of  chain  trig- 
gering is  not  evolved  in  time.  Therefore,  trigger  mechanism  cannot  model  concurrent  processes, 
e.g.  which  AGV  arrives  first  to  the  cell.  Also,  triggers  do  not  support  non-determinism,  and  the 
issue  of  controlling  the  future  is  not  applicable  to  them. 

Petri  net  formalism  [38]  is  used  to  model  various  kinds  of  dynamic  behavior.  Specifically, 
a  complex  system  can  be  modeled  as  a  set  of  conditions  (places),  a  set  of  events  (transitions) 
tied  together  in  a  network.  Conditions  can  be  defined  as  assertions  about  the  system  state  (see 
the  example  in  section  3.1  in  [38];  this  is  also  the  case  in  MERISE  [42],  where  conditions  are 
called  synchronizations).  Assertions,  that  are  currently  true,  are  marked  with  tokens  in  Petri  nets. 
Dynamic  laws  are  modeled  by  "firing"  transitions  which  change  the  set  of  currently  valid  assertions 
(notice  the  similarity  with  the  truth  maintenance  systems  [18]).  Petri  nets  have  the  following 
weak  points.  First,  it  requires  a  large  number  of  conditions  to  describe  the  state  of  a  complex 
system.  Secondly,  these  conditions  should  be  known  in  advance.  Thirdly,  Petri  nets  do  not  solve 
racing  problem  (section  3.2  in  [38];  especially,  p.  40  and  Figure  3.8).  Finally,  Petri  nets  can  model 
non-determinism;  but  it  is  difficult  to  define  goals  and  search  for  judicious  decisions  using  them. 

Still  another  area,  related  to  complex  systems  is  qualitative  physics  (QP)  [1,15].  This  is  a  branch 
of  AI,  interested  in  qualitative  predictions  about  the  future  states  of  physical  and  engineering 
systems  when  some  perturbation  moves  the  system  away  from  the  equilibrium.  The  state  of  the 
system  is  described  as  a  vector  in  QP.  Dynamic  laws  are  expressed  in  terms  of  confluence  equations, 
which  are  qualitative  analogs  of  differential  equations.  QP  deals  with  causality  and  non-determinism 
[15].  However,  the  QP  modeling  is  limited  to  restricted  classes  of  physical  and  engineering  systems. 
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Also,  the  state  of  the  system  is  described  as  a  vector,  which  is  unsuitable  for  complex  systems. 
Moreover,  confluence  equations  are  not  powerful  enough  to  model  dynamic  laws:  they  produce 
artificial  non-determinism,  whereas  the  underlying  physical  system  is  deterministic. 

3     Predicting  the  Future 

The  model  of  a  Complex  System,  defined  in  the  previous  section,  can  be  used  to  predict  the  future. 
Specifically,  we  can  ask  certain  questions  about  the  future  states  of  the  complex  object,  and  get 
the  answers  by  iteratively  applying  transformation  rules.  To  do  that,  we  need  a  Futuristic  Query 
Language  (FQL). 

We  do  not  completely  specify  our  FQL  in  this  report.  Complete  description  of  FQL  can  be 
found  in  [51].  We  only  present  the  salient  ideas  behind  the  definition  of  this  language. 

FQL  is  very  closely  related  to  historic  query  languages.  However,  there  are  three  basic  differences 
between  them.  Historic  query  languages  deal  with  two  kinds  of  time:  logical  time  (when  event 
occurred)  and  physical  time  (when  it  was  recorded  in  the  database)  [30,44].  In  contrast,  futuristic 
databases  have  only  one  kind  of  time.  Also,  an  FQL  can  contain  "indefinite-time"  queries,  using 
temporal  logic  operators  such  as  eventually  and  henceforth.  Historic  languages  can  refer  to  the  data 
in  the  finite  past  only.  Finally,  a  futuristic  query  can  refer  to  the  future  events.  For  example,  we 
want  to  know,  how  many  chairs  an  FMS  will  produce  in  an  hour.  To  the  contrary,  historic  query 
languages,  traditionally,  ask  queries  only  about  past  states.  Observe,  that  outside  these  differences, 
the  two  languages  are  identical.  Therefore,  to  simplify  the  discussion,  we  define  a  historic  query 
language  for  the  CO  model  with  one  kind  of  time,  and  use  it  as  a  futuristic  query  language  with 
time  moving  forward.  The  resulting  language  wLU  be  a  subset  of  the  complete  futuristic  query 
language;  it  will  be  a  basis  for  the  development  of  the  complete  language. 

To  define  a  futuristic  query  language,  we  have  to  start  with  a  static  one.  We  have  chosen  HDBL 
[39],  a  language  based  on  the  NF'^  model,  as  the  foundation  for  the  static  query  language.  HDBL 
has  to  be  extended  to  accommodate  additional  features  of  CO  not  included  in  NF^  model.  After 
that,  the  language  has  to  be  extended  again  to  accommodate  the  temporal  component. 

Alternatively,  we  could  have  started  with  one  of  existing  historic  or  temporal  query  languages, 
many  of  which  are  referred  to  in  [45]  and  are  compared  to  the  language  TQuel,  proposed  in  that 
reference.  Most  of  these  languages  are  based  on  the  relational  model.  Therefore,  these  languages 
have  to  be  extended  to  the  CO  model.  Naturally,  the  ideas  from  both  approaches  (historic  languages 
for  relational  model  and  static  languages  for  CO  model)  can  be  combined  together  in  order  to  define 
historic  (and  futuristic)  language  for  the  CO  model. 

Note,  however,  that  query  processing  strategies  for  futuristic  and  historic  query  languages  are 
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different.  Queries  against  historic  databases  retrieve  stored  data,  whereas  futuristic  queries  cannot 
access  data  because  it  has  not  materialized  yet.  We  will  discuss  query  processing  of  futuristic 
queries  later  in  this  section. 

Production  systems  in  AI  also  pose  queries  and  provide  answers  to  these  queries  by  running 
simulation.  However,  there  are  differences  between  them  and  futuristic  queries.  First  of  all,  the 
latter  queries  are  about  the  future.  Since  time  is  not  defined  explicitly  in  production  systems,  their 
queries  are  not  truly  futuristic  queries.  Secondly,  there  are  no  systematically  defined  declarative 
query  languages  for  production  systems,  to  the  best  of  the  authors'  knowledge.  Finally,  we  empha- 
size the  importance  of  query  optimization,  and  we  propose  an  efficient  query  processing  algorithm 
in  this  report.  Our  approach  is  geared  towards  large  databases.  As  was  the  case  with  Prolog  and 
Smalltalk,  production  systems  do  not  address  the  problem  of  efficient  query  processing  to  the  full 
extent.  Therefore,  we  believe  there  is  potentiaJ  for  many  additional  improvements  in  processing 
futuristic  queries.  We  are  making  the  first  step  in  this  direction  by  introducing  our  futuristic  query 
processing  algorithm. 

For  any  FQL  to  be  "complete",  we  believe  that  it  must  include  at  least  the  following  two  basic 
types  of  queries: 

•  "Find  Xi,X2,...,A'„  at  time  t  for  a  given  initial  state  of  CO  such  that  R(Ari,  JTj,..  .,X„) 
holds  at  t  and  Xi  6  d  for  all  i  for  t=0",  where  R  is  a  relationship  in  a  CO,  against  which 
the  query  is  asked,  C,  is  a  constant  and  9  a  relational  operator.  For  example,  "Find  in  which 
cell  the  chair  'CH23'  will  be  in  10  min",  i.e.  "Find  cell  such  that  L2(chair,cell)  at  t=10  and 
chair='CH23'  ". 

•  Path  queries:  "Find  X1.X2.--.Xn  at  time  t,  such  that  Xi  9  C,  for  f=0'',  where  X,  are 
subobjects  that  form  a  path,  e.g.  find  Chair.Status  for  Chair  =  'CH23'  in  20  min. 

We  will  define  formal  semantics  for  these  two  types  of  queries  and  propose  various  query  processing 
strategies  for  them. 

Complex  Systems  give  rise  to  a  simulation  process.  We  will  define  operational  semantics  of 
this  process  now.  It  will  be  based  on  the  recognize- act  cycle  of  production  systems,  like  0PS5. 
However,  our  semantics  will  be  different  from  the  one  for  0PS5  because  of  the  following.  First, 
0PS5  inference  engine  applies  only  one  action  per  cycle  and  we  consider  parallel  actions  a£  well. 
Second,  conflict  resolution  is  based  on  the  rule  precedence  in  our  case  and  not  on  the  refraction 
and  recency  heuristics  as  in  0PS5.  Third,  0PS5  does  not  let  the  same  rule  fire  twice  on  the  same 
data.  This  is  called  refraction  [10].  In  contrast,  we  prohibit  the  same  rule  firing  twice  only  during 
the  execution  of  the  actions  of  the  rule.  Finally,  0PS5  does  not  support  Integrity  Constraints,  time 
and  non-determinism. 
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The  simulation  process,  proposed  in  this  report,  is  not  the  only  one  possible.  In  fact,  we  are 
currently  trying  to  find  a  common  ground  behind  various  alternative  apprcwiches  to  the  semantics 
of  a  recognize-act  cycle. 

Semantics  considered  in  the  simulation  literature,  e.g.  event  scheduling  and  activity  scanning 
approaches  of  Zeigler  [57,  Ch.  7],  is  not  applicable  to  Complex  Systems  for  the  following  reasons. 
Even  though  time  is  considered  explicitly  in  the  simulation  literature,  IC's  are  not.  Also,  the 
"forward  movement"  in  time  is  bjised  on  a  transition  function  in  the  simulation  literature.  That  is, 
given  the  current  state  of  a  system,  completion  times  of  the  scheduled  events  and  a  given  completed 
event,  one  can  determine  the  sequence  of  events  that  will  be  triggered  by  this  completed  event  and 
by  the  completion  times  of  the  scheduled  events.  In  Complex  Systems,  the  forward  movement  is 
materialized  by  a  radically  different  method,  i.e.  by  the  inference  engine  which  is  based  on  the 
recognize-act  cycle. 

We  introduce  some  preliminary  notions  now  to  be  used  in  the  Simulation  Algorithm.  Then, 
we  will  explain  the  intuition  behind  it.  Finally  we  will  present  the  algorithm  itself.  We  define 
operational  semantics  of  simulation  with  an  algorithm,  and  we  will  not  be  concerned  with  its 
efficiency.  Efficiency  issues  will  be  addressed  below  when  we  introduce  the  Propagation  Algorithm. 

At  first,  we  will  extend  the  class  of  formulas  appearing  in  preconditions  and  integrity  constraints 
to  a  special  case  of  many-valued  logic  [41]  with  3  truth  values  {  f,  ?,  t}.  It  will  be  called  3-valued 
logic.  Intuitively,  ?  stands  for  "maybe",  i.e.  maybe  TRUE  or  maybe  FALSE.  Standard  logical 
operations  are  extended  to  accommodate  ?  as  follows. 

fA?  =  f        fV?  =  ?     -1?=?  (3a:)P(x)  =  t  if  P(c)  for  some  c 

?  A  ?=  ?        ?  V  ?=  ?  (3a;)P(x)  =  ?  if  P(c)  i^  t  for  all  c  and  P(c)  =  ?  for  some  c 

t  A  ?=  ?        t  V  ?=  t  (3i)P(x)  =  f  otherwise 

Ka  tuple  belongs  to  a  relationship,  it  is  evaluated  to  t  in  the  classical  2-valued  logic,  otherwise,  to 
f.  To  distinguish  the  third  possibility  in  the  3-valued  logic,  some  of  the  subobjects  and  relationship 
Instances  of  a  given  CO  will  be  marked  with  ?.  If  a  relationship  instance  (oi, . . .  ,a„)  G  .R  is  marked 
with  ?  then  R(a\,. . .  ,a„)  =  ?.  If  a  subobject  is  marked  with  ?  ,  all  the  relationship  instances,  in 
which  the  subobject  participates,  are  marked  with  ?. 

The  satisfiability  set  SAT(R,CO)  for  a  given  complex  object  CO  and  a  transformation  rule 
R  is  defined  as  follows.  Let  the  precondition  of  R,  Pru,  contain  the  variables  {ii}t=i,...,n,  i-e. 
Prji  is  a  predicate  Prfi{xi,X2,.. .  ,Xn)-  Substitute  all  the  possible  values  c,  for  all  the  vari- 
ables X,.  Evaluate  the  precondition  formula  for  each  such  substitution  using  the  3-valued  logic 
and  the  marks  ?  placed  on  items  of  CO.  The  result  of  the  evaluation  is  the  set  of  tuples  X 
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=  {ci,C2,...,c„  I  Prfi{ci,C2,...,Cn)  =  t] .  ^  Let  the  action  part  of  the  rule  R  have  vari- 
ables Vi,...  ■,ym,Zi,----,Zk-  Without  loss  of  generality,  assume  that  the  variables  y,  are  among 
the  variables  Xi  in  the  precondition  Ptr,  and  z,-  are  not.  Let  2,  range  over  a  domain  Di  for 
t  =  1,. .  .,A;.  Let  C  be  obtained  from  X  by  projecting  X  on  the  attributes  of  variables  y,.  Let  C 
=  C  X  doTn{Di)  X  ...  X  dom{Dk).  For  each  path  variable  of  the  form  x.y,  appearing  among  the 
action  variables,  where  x  and  y  are  defined  over  dom{Dx)  and  dom{Dy)  respectively,  remove  those 
tuples  from  C,  which  projections  on  D^  X  Dy  do  not  belong  to  the  PARENT/CHILD  relationship 
between  elements  of  Dx  and  Dy  in  the  complex  object.  The  resulting  set  is  the  satisfiability  set 
SAT(R,CO).  If  SAT(R,CO)  ^  0  then  we  say  that  R  matches  against  CO. 

Example  4.  Assume  that  the  FMS  has  three  AGVs,  {Al,  A2,  A3},  three  cells,  {CI,  C2,  C3} 
and  three  chairs,  {chl,  ch2,  ch3}.  Let  the  state  of  FMS  be  Ll{(chl,Al),  (ch3,A3)},  L2{(ch2,C2)}, 
D1{(A1,C1),  (A2,C2),  (A3,C3),  (A3,C2)},  ch.stat{(chl,2),  (ch2,2),  (ch3,2)},  M{(1,1),  (2,2),  (3,3)}, 
cell_type.ceU{(l,Cl),  (2,C2),  (3,C3)}.  Let  relationship  instances  D1(A3,C3)  and  D1(A3,C2)  be 
marked  with  ?  ,  meaning  that  the  AGV  A3  is  in  the  process  of  moving  from  the  cell  C3  to  C2. 
Then  SAT(R1,FMS)  for  the  rule  Rl: 

precondition:  D1(AGV,  celLtype.ceU)  and  Ll(chair,AGV)  and 
M(chair.status,  cell-type')  and  not  FINISHED(chair) 
action:  DEL_REL(Dl,AGV,ceU);  INS_REL(Dl,AGV,celLtype'.ceU') 
time:  tl(AGV,ceU,ceU') 

from  the  Example  3  is  computed  as  follows.  The  set  X  =  {(Al,Cl,chl, 1,1,2)};  the  last  three  numbers 
stand  for  status,  cell.type  and  ceU.type'  variables  respectively.  Observe  that  the  substitution 
(A3,C3,ch3,2,3,2)  for  the  variables  in  the  precondition  of  Rl  is  not  included  in  X  because  D1(A3,C3) 
=  ?,  and  the  precondition  yields  ?.  The  set  C  is  {(Al,Cl,2)},  where  2  stands  for  the  next  cell  type 
and  C  =  {(A1,C1,2,C1),(A1,C1,2,C2),(A1,C1,2,C3)}.  Finally,  SAT(R1,FMS)  =  {(A1,C1,2,C2)} 
because  only  the  cell  C2  is  of  the  type  2. 

■ 
SAT  defines  a  set  of  bindings  for  the  variables  in  the  action  part  of  a  rule,  or  an  instantiation 
set  [10].  Each  tuple  of  SAT  defines  a  specific  assignment  of  values  to  variables  in  the  action 
part.  This  variable  assignment  determines  completion  time  of  rule  actions.  We  assume  that  aU 
elementary  actions  of  a  rule  start  and  finish  at  the  same  time.  Therefore,  completion  time  is 
the  same  for  all  the  elementary  actions  of  a  rxde.  For  example,  consider  the  MOVE  operation 
M0VE(C1,D1,A1,D1,C2).    It  consists  of  the  two  operations  DELETE  and  INSERT.  Note  that 


*Note  that  the  tuples,  evaluated  to  ?  were  not  included  in  this  set. 
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DELETE(D1,A1,C1)  and  INSERT(D1,A1,C2)  occur  instantaneously  in  the  FMS  system,  but  it 
takes  some  time  t  for  the  vehicle  Al  to  move  from  the  cell  Cl  to  C2.  This  situation  is  modelled  as 
if  INSERT  and  DELETE  operations  take  the  same  time  t  to  complete. 

A  set  of  elementary  operations  to  be  performed  for  a  given  rule  R,  matched  against  a  com- 
plex object  CO,  is  determined  as  follows.  We  start  with  the  computation  of  the  satisfiability  set 
SAT(R,CO).  Then,  if  R  is  non-deterministic,  a  set  of  non-deterministic  choices  has  to  be  made. 
These  choices  define  a  subset  of  tuples  DSAT(R,CO)  in  SAT(R,CO).  For  example,  if  a  vehicle  is 
selected  to  be  moved  to  a  certain  cell,  then  the  tuples  corresponding  to  other  cells  do  not  belong  to 
DSAT.  After  that,  a  set  of  elementary  operations  is  determined  for  each  tuple  in  DSAT  as  follows. 
For  each  elementary  operator,  take  its  variables  and  bind  them  to  the  values  corresponding  to  the 
variables  in  the  DSAT  tuple.  For  example,  the  SAT  tuple  from  Example  4  yields  two  elementary  op- 
erations DEL_REL(D1,A1,C1)  and  INS_REL(D1,A1,C2).  The  completion  time  for  the  elementary 
operations  is  determined  by  the  completion  time  for  the  DSAT  tuple  as  discussed  in  the  previous 
paragraph.  Each  elementary  operation,  computed  so  far,  should  be  checked  to  see  if  it  is  not  an 
idle  one,  i.e.  there  is  an  item  to  be  deleted  if  it  is  DELETE,  and  there  is  no  item  in  the  complex 
object  identical  to  the  one  to  be  inserted,  if  the  operation  is  INSERT.  The  resulting  set  determines 
the  set  of  operations  to  be  performed  for  a  given  rule  on  a  given  complex  object. 

The  simulation  process  works  as  follows.  Transformation  rules  are  matched  against  the  CO  one 
at  a  time  according  to  their  priorities.  Note  that  the  matching  is  done  in  the  3-valued  logic.  If  a  rule 
matched  against  the  CO,  one  of  its  alternative  sequences  of  actions  is  selected  non-deterministically 
and  is  scheduled  to  complete  operation  on  the  matched  data  sometimes  in  the  future.  Meanwhile, 
the  matched  data  is  marked  with  ?.  Once  an  item  (relationship  instance  or  a  subobject)  is  marked 
with  ?,  3-valued  logic  guarantees  that  this  item  will  not  be  accessed  by  other  transformation  rules 
before  completion  of  the  rule  that  marked  the  item.  Its  status  wiU  be  "invisible"  to  other  rules. 
Before  a  given  transformation  rule  completes  its  execution,  other  rules  are  matched  against  the 
CO  with  some  items  being  marked  by  the  previously  matched  rules.  Finally,  when  a  rule  finishes 
its  execution,  it  removes  ?  marks  from  the  data  marked  by  that  rule,  performs  rule  actions  and 
checks  if  IC's  are  not  violated  by  these  actions.  If  IC's  are  not  violated,  the  changes  become 
permanent;  otherwise,  execution  of  the  current  non-deterministic  alternative  is  terminated.  The 
process  of  matching,  scheduling  and  execution  of  transformation  rules  continues  until  either  it  is 
stopped  or  no  more  rules  can  match  the  complex  object.  Observe  that  the  simulation  process  is 
done  non-deterministically:  many  non- deterministic  simulations  are  executed  in  parallel  because  of 
the  non-deterministic  nature  of  transformation  rules. 
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Incomplete  actions  of  transformation  riiles  will  be  stored  in  the  ACT  set,  which  is  the  set  of 
triples  {t,R,0),  where  t  is  time  when  the  operation  O  finishes,  and  R  is  the  transformation  rule 
that  caused  that  action.  ACT  will  be  implemented  as  a  priority  queue  with  the  lexicographical 
order  on  t  and  R.  A  priority  queue  supports  3  types  of  operations:  MAKENULL,  INSERT  and 
DELETEMIN.  MAKENULL  empties  the  queue.  INSERT(q,Q)  adds  the  tuple  q  to  Q  based  on 
the  priority  of  q.  DELETEMIN(q,(3)  removes  the  top  entry  from  the  queue  Q  and  returns  it  in 
the  parameter  a. 

The  Simulation  Algorithm  is  presented  in  Fig.  2.  It  returns  a  single  non-deterministic  alterna- 
tive. It  is  straightforward  to  extend  it  to  the  case  when  all  the  non-deterministic  alternatives  are 
computed. 

Observe  the  following  points  about  the  algorithm.  Insertions  are  done  at  the  be^nning  of 
an  action,  whereas,  deletions  and  updates  at  the  action  completion  time.  All  operations  mark 
items  with  ?at  the  beginning  of  an  action;  therefore,  transitory  data  cannot  be  "seen"  by  other 
transformation  rules.  Also,  IC's  are  checked  at  the  completion  time;  however,  their  violation  does 
not  cause  cascading,  as  was  justified  before.  Finally,  when  the  Simulation  Algorithm  stops  because 
the  final  time  T  has  been  reached,  the  priority  queue  ACT  may  be  not  empty.  Since  all  the 
operations  in  that  queue  are  scheduled  at  times  t  >  T,  they  should  not  be  executed. 

Example  5.  Assume  FMS  has  three  cells  Cl,  C2,  C3,  two  AGVs  Al,  A2  and  two  chairs 
chl,  ch2.  Let  the  initial  state  of  FMS  be  Ll{(chl,Al)},  L2{(ch2,C2)},  D1{(A1,C1),  (A2,C2)}, 
ch.stat{(chl,2),  (ch2,2)},  M{(1,1),  (2,2),  (3,3)}.  Let  Rl  x  R2  X  R3  -!  R4  and  T  =  3.  Time 
functions  for  the  rules  Rl,  R2,  R3  and  R4  are  defined  as  follows.  t3(2,2)  =  2  for  R3,  and  all  the 
values  of  all  other  functions  are  equal  to  1. 

At  time  t  =  0,  rules  Rl  and  R3  match  against  FMS.  However,  R3  has  higher  priority  and  is 
applied  first.  Satisfiability  set  for  R3  is  SAT(R3,FMS)  =  (ch2,2).  Completion  time  for  that  tuple 
IS  t  =  2.  Elementary  operations  {"insert  a  chair  part  Part^  into  ch2'',  "ch2.6tat=ch2.stat-|-l"} 
are  added  to  the  priority  queue  ACT.  Satisfiability  set  for  Rl  is  SAT(R1,FMS)  =  (C1,A1,2,C2) 
and  the  elementary  operations  {DELETE(D1,A1,C1),  INSERT(D1,A1,C2)}  are  added  to  ACT. 
The  relationship  link  D1(A1,C2)  is  inserted  in  the  FMS  and  the  following  items  are  marked  at 
time  t  =  0:  D1(A1,C1),  D1(A1,C2)  and  "stat"  for  ch2.  At  the  end  of  t  =  0,  ACT  is  {(1, 
Rl,  DELETE(D1,A1,C1)),  (1,  Rl,  INSERT(D1,A1,C2)),  (2,  R3,  "INSERT"),  (2,  R3,  "ch2.stat 
=  ch2.stat-|-r)}. 

At  t  =  1,  the  operations  DELETE(D1,A1,C1)  and  INSERT(D1,A1,C2)  of  rule  Rl  are  re- 
moved from  ACT.  The  operation  DELETE(D1,A1,C1)  is  performed  and  the  relationship  instances 
D1(A1,C1)  and  D1(A1,C2)  are  unmarked.  The  new  value  for  Dl  is  D1{(A1,C2),  (A2,C2)}.  This 
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operation  does  not  violate  the  IC's;  therefore  it  is  not  aborted.  The  only  rule  that  matches  against 
FMS  at  t  =  1  is  R3.  It  matched  at  t=0  and  again  at  t=l  because  no  changes  occurred  in  the 
cell  C2.  However,  the  status  of  ch2  was  marked  with  ?;  this  results  in  the  rule  match  returning  ?. 
Therefore,  the  rule  R3  is  not  applied  twice.  Notice  that  R2  does  not  match  against  FMS  for  t  =  1 
because  there  is  still  the  chair  ch2  in  the  cell  C2.  Specifically,  L2(ch2,C2)  =  ?  and  the  precondition 
of  R2  is  evaluated  to  ?. 

At  t  =  2,  the  two  remaining  operators  of  R3  are  removed  from  the  priority  queue  and  executed, 
resulting  in  the  change  of  the  status  of  the  chair  ch2.  Also,  R4  matches  against  FMS  at  t  = 
2.  (ch2,A2)  is  added  to  LI,  and  L2(ch2,C2)  and  Ll(ch2,A2)  are  marked  with  ?.  R2  still  does 
not  match:  even  though  R4  initiated  the  movement  of  ch2  out  of  the  cell  C2,  the  marked  link 
L2(ch2,C2)  still  remained;  this  resulted  in  the  precondition  of  R2  being  evaluated  to  ?  and  in  no- 
match  situation.  ACT  =  {  (3,  R4,  DELETE(L2,ch2,C2)),  (3,  R4,  INSERT(Ll,ch2,A2))  }  at  the 
end  of  t  =  2.  Observe  that  if  the  chair  ch2  moved  out  of  the  cell  C2  completely,  then  R2  would 
match  against  FMS.  This  would  have  been  an  example  of  a  conflict  between  the  two  rules  R2  and 
R4,  i.e.  the  situation  when  the  state  of  a  system  depends  on  the  order  in  which  the  rules  are 
applied.  In  the  Simulation  Algorithm,  the  conflict  resolution  strategy  [32]  is  based  on  the  ordering 
among  the  transformation  rules. 

At  t  =  3,  the  MOVE  operator  is  removed  from  ACT  and  is  executed.  Finally,  R2  matched 
against  FMS  because  L2(ch2,C2)  =  f  at  this  point.  However,  the  actions  of  R2  were  placed  on  the 
ACT  queue  and  remained  there  until  the  simulation  stopped.  The  final  state  of  FMS  at  time  t  = 
3  is  Ll{(chl,Al),  (ch2,A2)},  L2  =  0,  D1{(A1,C2),  (A2,C2)},  ch.stat{(chl,2),  (ch2,3)}. 

■ 

The  simulation  algorithm  defines  semantics  of  the  temporal  queries.  Let  F  :  CS  x  T  — ►  ■p(CO) 
be  the  function  computed  by  the  simulation,  where  CS  is  the  class  of  Complex  Systems,  CO  is 
the  class  of  complex  objects,  T  is  time  (i.e.  the  set  of  natural  numbers),  and  V  is  the  power 
set  operation  on  complex  objects.  Thus,  F  takes  a  complex  system  and  a  time  instance  and 
produces  a  set  of  feasible  complex  objects  (non-determinism  allows  more  than  one).  Let  ST  : 
QBx  —*■  Q,  where  QBx  is  the  class  of  basic  queries  defined  above,  Q  is  the  set  of  "static"  basic 
queries,  i.e.  basic  queries  from  which  time  is  removed.  ST  removes  time  from  a  basic  query.  For 
instance,  application  of  ST  to  the  first  basic  query  in  the  example  above  yields  "Find  cells  such 
that  L2('CH23',cell)''.  Then  the  semantics  of  a  basic  temporal  query  QBt  €  QBx  is  defined 
by  the  mapping  f  :  QBx  x  CS  x  T  ^  "PCCO)  as  ltQ5r,CS,t)  =  (ST(QBr))  (F(CS,t)).  The 
meaning  of  this  formula  is:  run  simulation  first,  and  apply  the  query  ST(QBt)  to  the  result  of 
the  simulation.  Observe  that  ST{QBt)  is  a  time  independent  query  and  is  applicable  to  the  set  of 
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complex  objects  F(CS,t). 

The  Simulation  Algorithm  is  inefficient  for  the  following  two  reasons.  First,  the  same  predicates 
occurring  in  preconditions  of  different  rviles  are  evaluated  several  times  instead  of  one.  Secondly, 
some  rules  that  do  not  contribute  to  the  answer,  are  evaluated.  An  algorithm  that  eliminates  these 
inefficiencies  will  be  presented  below. 

In  this  algorithm,  we  assume  that  time  in  the  transformation  rules  is  a  constant  function  and 
is  always  equal  to  1.  We  will  also  sketch  the  extended  version  of  the  algorithm  when  time  is  an 
arbitrary  function  of  the  state.  See  [51]  for  a  detailed  presentation  of  the  extended  version.  Some 
preliminary  definitions,  that  will  be  used  in  the  algorithm,  foUow. 

Define  the  set  S  of  maintained  relationships  as  the  union  of  both  all  the  CO  relationships  and  all 
the  paths  in  preconditions  of  aU  the  transformation  rules.  ''  For  instance,  for  the  rules  in  Example 
3,  S  =  {  ii,  Di,Z<2,  M,  chair.status,  celLtype.cell  }.  If  no  confusion  arises,  we  wiU  call  elements  of 
S  relationships,  thus  omitting  the  word  "maintained". 

Define  the  propagation  graph  for  a  given  complex  system  (CO,TR)  as  a  directed  bipartite 
graph  G  =  (R  U  S  ,  E),  where  R  is  the  set  of  all  transformation  rules  in  TR  and  S  is  the  set  of 
maintained  relationships.  R  and  S  form  the  two  groups  in  the  bipartite  graph.  Elements  of  R  and 
S  will  be  called  R-nodes  and  P-nodes  respectively.  There  are  two  kinds  of  edges  in  E: 

•  (P,R)  e  E  if  P  is  a  maintained  relationship  occurring  in  the  precondition  of  the  transformation 
rule  R; 

•  (R,P)  G  E  if  either  P  is  a  CO  relationship  in  some  action  of  R;  or  P  is  a  path,  and  some 
action  of  R  has  the  form  P=f(P). 

Fig.  3  shows  the  propagation  graph  for  the  FMS  from  Example  3.  Actually  four  edges  are 
massing  in  the  diagram,  namely  the  edges  from  the  maintained  relationship  cell_type.cell  to  Rl, 
R2,  R3,  and  R4.  We  have  chosen  not  to  show  them  to  avoid  excessive  cluttering  of  the  diagrams 
of  propagation  and  of  the  trace  (Fig.  5)  graphs.  ^  This  wiU  not  lead  to  any  problems  because 
ceU.type.cell  is  a  static  relationship,  i.e.  it  is  never  changed  in  the  simulation  process.  The  role 
of  ceU_type.ceU  in  the  Propagation  Algorithm,  presented  below,  is  the  same  as  the  role  of  static 
relationship  "match",  M  :  it  wiU  appear  only  in  one  place  in  the  algorithm,  namely  when  the 
precondition  is  evaluated  against  the  maintained  relationships.  Therefore,  the  reader  can  easily 
add  cell_type.cell  to  the  diagrams  of  propagation  and  the  trace  graphs  and  incorporate  it  in  the 
algorithm. 


^Observe  the  difference  between  maintained  and  CO  relationships.  Maintained  relationship  may  include  some  CO 
relationships  (that  are  real  relationships)  and  some  paths,  which  are  terms. 
*Trace  graph  will  be  defined  later. 
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Satisfiability  set  SAT(R,CO)  was  defined  before,  using  3-valued  logic.  However,  in  this  case, 
aU  actions  are  performed  in  one  unit  of  time.  Therefore,  no  markings  with  ?  will  be  required,  and, 
consequently,  3-valued  logic  will  not  be  used.  This  will  not  affect  the  definition  of  SAT.  Simply,  all 
evaluations  of  formulas  will  be  performed  in  the  classical  2-valued  logic.  For  instance,  in  Example 
3,  SAT(R3,FMS)  =  {(chl,  1),  (ch2,  3)}  is  the  value  for  (chair,  status)  based  on  the  state  of  the 
CO  shown  in  Fig.  4.  Observe,  that  the  values  for  'cell'  have  been  projected  out. 

Propagation  Algorithm  provides  an  answer  to  a  basic  query  Q:  {xi, . . .  ,a;jt|Q(xi, . . .  ,1*)  A  Q  € 
S  A  XiOci}  at  time  T,  where  Q  is  either  a  CO  relationship  or  a  path,  Ci  is  a  constant  and  6  a 
relational  operator. 

It  consists  of  two  main  stages.  In  the  first  stage,  we  go  backwards  in  time  from  query  Q  to  find 
all  the  transformation  rules  and  maintained  relationships  that  affect  Q.  This  is  done  by  "unwinding" 
the  propagation  graph,  starting  with  the  query  node  Q,  to  build  the  trace  DAG.  The  trace  DAG 
for  the  FMS  example  is  shown  in  Fig.  5.  The  DAG  consists  of  layers.  Each  layer  has  P-nodes, 
R-nodes  and  edges  from  P-  to  R-nodes  of  the  propagation  graph.  The  two  layers  are  connected 
by  the  edges  from  R-nodes  to  P-nodes  of  the  graph.  Also,  restrictions  Xi  0  Ci  are  passed  down  the 
trace  DAG.  We  will  use  the  following  notation  in  the  algorithm.  0(V)  is  the  set  of  restrictions, 
associated  with  the  node  V  (either  P-  or  R-node)  of  the  trace  DAG.  If  (P,R)  G  E,  then  Trp{Q{R)) 
is  the  set  of  those  restrictions  for  P-node  P,  obtained  from  restrictions  for  R-node  R,  which  refer 
to  some  variable  of  the  maintained  relationship  associated  with  P.  It  is  a  projection  of  restrictions 
in  R  on  variables  in  P. 

Construction  of  the  trace  DAG  exhibits  some  similarity  with  building  the  rule-goal  trees  [54]  in 
the  compiled  approach  to  query  processing  in  deductive  databases.  However,  the  rule-goal  formal- 
ism cannot  be  applied  to  our  problem  because  actions  can  refer  to  several  maintained  relationships 
(therefore,  the  structure  is  a  DAG,  not  a  tree);  and  because  deletions  are  allowed  in  transformation 
rules,  and  not  only  insertions. 

In  the  second  stage,  we  move  bottom-up  in  the  trace  DAG,  maintaining  the  set  of  relationships 
Val(P)  for  each  P  in  S  .  This  stage  is  similar  to  the  Simulation  Algorithm.  However  irrelevant 
transformation  rules  are  not  evaluated  because  they  have  been  eliminated  in  the  first  stage. 

We  will  use  "reverse"  adjacency  list  representation  for  the  graphs:  vertex  v  belongs  to  Adj(G,w) 
for  graph  G=(V,E)  if  (v,w)  €  E.  It  will  make  the  presentation  simpler.  We  assume  that  some  total 
order  is  defined  on  the  transformation  rules.  The  rules  are  processed  in  that  order  in  case  of 
conflicts. 

Propagation  Algorithm 
Inputs:  1.  (CO,TR),  complex  system;  2.  Q,  the  basic  query  and  the  set  of  restrictions  for  Q  of 
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the  form  XiBci.  3.  T,  future  time  instance  when  Q  returns  the  answer;  4.  -<,  total  order,  imposed 
on  transformation  rules  TR;  5.  G  =  (V,E),  propagation  graph  for  the  complex  system.  ^ 
Outputs:  One  of  non-deterministic  answers  to  the  query  Q  at  time  T. 

The  algorithm  is  presented  in  Fig.  6. 

Notice  that  in  the  second  stage  of  the  algorithm,  the  transformation  rules  at  time  t  are  applied 
in  the  predefined  order  based  on  -<.  Hence,  if  the  two  rules  conflict,  the  one  with  the  higher  order 
fires  first.  Therefore,  the  conflict  resolution  strategy  [32]  is  based  on  the  predefined  order.  This  is 
in  accordance  with  classical  production  systems.  Also  notice  that  Propagation  Algorithm  returns 
oidy  one  of  possible  answers  because  of  the  non-deterministic  choice  made  in  the  sixth  line  from  the 
bottom.  However,  extension  to  the  algorithm  that  returns  all  possible  answers  is  straightforward. 

Example  6.  Consider  FMS  again.  Fig.  3  shows  the  propagation  graph.  We  have  chosen 
to  omit  the  edges  from  celLtype.cell  to  Rl,  R2,  R3  and  R4  to  avoid  excessive  cluttering  of  the 
diagram.  The  initial  state  of  maintained  relationships  S  is  shown  in  Fig.  4.  The  rule  order  is 
R\  <  R2  <  R'i  -<  RA.  However,  no  conflict  resolutions  is  required  in  this  simple  example. 

Consider  a  query  "In  which  cell  the  chair  'Ch2'  will  be  at  time  T=3?"  or  alternatively,  "Find  C 
s.t.  L2('Ch2',C)  at  time  T=3''.  The  trace  DAG  is  shown  in  Fig.  5.  Time  increases  from  the  top  to 
the  bottom  in  the  figure.  Restrictions  are  shown  next  to  the  vertices  of  the  DAG.  We  have  chosen 
the  concise  notation  for  restrictions,  e.g.  0(ch2)  and  not  0(chair  =  'ch2'),  to  save  space  in  the 
diagram.  All  the  restrictions  become  empty  for  all  the  relationships  starting  with  t=2.  Therefore, 
we  have  omitted  the  empty  restrictions  starting  at  level  2.  Observe  that  0(ch2)  has  not  been  passed 
from  R2  to  L2  at  level  t=l  because  t:l2{Q{R2))  =  0.  Also,  note  that  0(i?2)  at  t  =  2  is  equal  to 
0(il)  V  0(12).  Since  0(X2)  =  0,  this  makes  0(i?2)  =  0,  i.e.  no  restriction  on  R2  for  t=2. 

Values  of  maintained  relationships,  Val,  are  shown  next  to  the  relationships  at  each  level  of  the 
DAG  (they  are  framed  in  rectangular  boxes).  "-I-"  next  to  a  transformation  rule  indicates  that 
the  rule  provides  a  non-empty  satisfiability  set.  Observe  that  selection  0(ch2)  was  used  in  the 
evaluation  of  rvde  R2  for  t  =  I.  The  algorithm  yields  the  answer  that  'ch2'  will  be  in  'C3'  at  time 
t  =  3. 

■ 

The  Propagation  Algorithm  assumes  that  time  functions  in  transformation  rules  are  constant 
because  of  the  explicit  restriction  made  above.  Here  is  a  sketch  of  the  extended  version  of  the  algo- 
rithm that  assumes  that  time  is  a  function  of  the  state  in  transformation  rules.  Both  propagation 
and  trace  graphs  remain  unchanged.  However,  individual  tuples  from  SAT  sets  are  "passed  up" 
the  trace  DAG  in  the  extended  version,  rather  than  SAT's  in  the  version  presented  above.  Also, 


"Strictly  speaking,  G  is  not  an  independent  input;  but  we  included  it  because  G  does  not  depend  on  a  specific 
query.  It  is  precomputed  for  the  algorithm. 
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Stage  1:     Bui/rf  the  trace  DAG  G'  =  (V,  E')  from  G 

t  -  0;    P[0]   -  Q;    R[0]   -  0;    £'  =  0 

0(Q)  "  initial  set  of  restrictions  {xi9c,}; 

repeat 

forall  R  G  R[t]   do 

Coapute  @(R)   as  logical  OR  of  restrictions 
iroB  e(P)  over  all  P  s.t.      Re.  Adj{G',P) 
if  P  6   AdjCG.K)   then 

add  P  to  P[t]   and  insert  (P.R)   into  £", 
(i.e.      add  P  to  AdjiG' .    R)) 
end 

forall  P  in  P[t]   do  ,.. 

Compute  ©(P)   as  logical  OR  of  restrictions  from 
Tp{e(R))  oTcr  all  R  s.t.      P  eAd}{G',R) 
if  R  e   AdjiG,?)   and  t<T  then 

add  R  to  R[t+1];   add  (R,P)   to  £".    i.e.     R  to  Adj(G' ,   P) 
end 

t  -  t  +   1; 
until  t  >  T 
Set  V'  =  uf=o(P[<]UR[t]) 

Stage  2:     Run  simulation  on  G' 

t  -  T; 

forall  sources  P  of  G'   do 

Evaluate  maintained  relationship  P  based  on  initial  state  of  CO 
and  set  Val(P)  to  it 
end 
while  t  >  0  do 

forall  R  €  R[t]  in  order  based  on  -<  do 

compute  S^Skl(.R,Adj(.G' ,K))  ,    i.e.   evaluate  precondition 
of  R  based  on  Val(P)  and  on  e(P)  for  P  €  AdjiG' ,K) ; 
if  S  7^  0  then 

select  one  of  the  non-deterministic  actions  of  R 
so  that  the  resulting  state  satisfies  IC's; 
if  such  an  action  exists  then 

perform  that  action;  update  Val(P)  for  P  s.t.  R  6  Adj{G' ,   P)  ; 
end 

t  -  t  -  1; 
end 
return  (Val(Q)) 


Figure  6:  Propagation  Algorithm 
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rule  synchronization  techniques  are  provided  to  resolve  conflicts  between  executions  of  concurrent 
actions.  Refer  to  [51]  for  details. 

The  main  weakness  of  the  "future  prediction"  approach,  as  presented  so  far,  lies  in  poten- 
tially too  many  non-deterministic  alternatives  in  the  answer  to  a  query.  The  chair  may  end  up 
in  potentially  too  many  cells  in  the  distant  future.  We  wiU  propose  the  mechanisms  to  reduce 
non-determinism  and  select  optimal  behavior  in  the  next  section. 

4     Controlling  the  Future 

By  controlling  the  future  we  mean  making  judicious  (optimal)  decisions  to  derive  beneficial  results 
in  the  future.  Optimal  decisions  are  associated  with  the  right  choice  among  non-deterministic 
alternatives  of  transformation  rules  in  a  Complex  System. 

To  define  optimality,  we  add  an  additional  parameter  to  the  notion  of  the  Complex  System,  its 
goals.  We  wiU  not  consider  multiple  criteria  systems  in  this  report,  and  restrict  ourselves  to  the 
single  goal  problem  or  to  the  weighted  average  of  several  goals.  An  optimization  problem  can  be 
stated  as  follows: 

Given  the  current  state  of  the  complex  system  and  the  system  goal,  select  those  non- 
deterministic  alternatives  that  optimize  this  goal,  subject  to  the  integrity  constraints 
and  dynamics  of  transformation  rules. 

For  instance,  the  goal  in  the  FMS  example  may  be  to  maximize  throughput  of  chairs.  Alterna- 
tively, a  more  realistic  goal  is  to  satisfice  the  production  rates  ^  and  to  niinimize  congestion  in  the 
system. 

The  solution  to  the  optimization  problem  can  be  found  using  techniques  of  operations  research 
(OR).  These  techniques  lie  outside  of  the  area  of  database  or  AI  research.  See  [12]  for  the  sur- 
vey of  these  techniques  for  FMS.  Most  of  the  FMS  techniques  are  based  on  queueing,  non-linear 
optimization  and  optimal  control  [8]  theories. 

The  solution  to  the  optimization  problem  accomplishes  two  objectives.  It  finds  the  best  type 
of  behavior  by  selecting  optimal  non-deterministic  alternatives.  Also,  it  converts  system  goals  into 
additional  constraints,  narrowing  the  scope  of  non-determinism.  For  instance,  in  our  FMS  example, 
the  solution  for  both  goals,  stated  above,  yields  the  following  optimal  policy: 

If  ail  AGV  can  be  sent  to  several  cells,  send  it  to  the  cell  with  the  smallest  number  of 
vehicles  docked  at  it. 


^Satisfice  means  to  approach  as  close  as  possible.    Production  rate  is  an  external  parameter  for  the  problem, 
specifying  how  many  chairs  to  produce  per  unit  of  time. 
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Note  that  this  policy  restricts  the  choice  of  candidate  cells.  We  do  not  present  derivation  of  this 
policy  here  because  it  utilizes  OR  methods  and  is  irrelevant  to  the  database  research. 

The  solution  to  the  optimization  problem  does  not  necessarily  make  the  system  deterministic. 
It  only  reduces  non-determinism,  in  general.  Therefore,  goals  are  converted  only  into  additional 
constraints,  and  the  system  can  still  remain  non-deterministic.  For  instance,  there  can  be  several 
cells  with  the  same  minimal  number  of  vehicles  docked. 

Observe  that  a  solution  to  the  optimization  problem  is  marginally  related  to  the  concept  of 
a  Complex  System  because  it  utilizes  classical  analytical  methods.  However,  the  optimization 
problem  is  stated  in  terms  of  CS:  it  takes  into  account  the  structure  of  CO,  and  dynamics  is 
expressed  in  terms  of  transformation  rules. 

5      Conclusion 

In  this  report,  we  propose  an  alternative  approach  to  behavioral  object-orientation.  The  state 
of  the  system  is  expressed  in  terms  of  the  complex  object  model,  and  the  behavior  in  terms  of 
transformation  rules.  Complex  object  model  and  transformation  rules  are  integrated  into  the 
concept  of  Complex  System  (CS). 

Complex  System  can  be  considered  as  an  extension  of  AI  production  systems  that  supports 
complex  objects,  time  and  non-determinism.  There  is  also  a  close  relationship  between  CS  and 
differential  and  recurrence  equations.  Therefore,  we  believe  that  the  CS  formalism  can  be  used 
successfully  in  modelling  those  applications  that  are  currently  being  described  by  operations  re- 
search methods,  such  as  Flexible  Manufacturing  Systems  (FMS).  We  have  shown  how  structural 
and  behavioral  properties  of  FMS  can  be  modelled  using  Complex  Systems. 

Complex  Systems  can  be  used  for  predicting  the  future  by  asking  futuristic  queries  expressed  in 
Futuristic  Query  Language.  A  practical  query  processing  algorithm  for  a  subset  of  such  a  language 
was  presented  which  was  based  on  simulation  procedure. 

We  aJso  considered  the  problem  of  controlling  the  future.  Since  CS  can  be  non-deterministic 
in  general,  there  can  be,  potentially,  too  many  alternative  answers  to  the  prediction  problem.  The 
control  problem  finds  the  best  kind  of  behavior,  thus  converting  system  goals  into  additional  con- 
straints utilizing  optimization  and  control  theory  techniques.  The  conversion  process  was  illustrated 
using  FMS  again. 
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Figure  la.  Products  Manufactured  by  FMS 


Complex  Entity  (CE) 


FMS 


AGV      load/unload 

A 


cell_type 


tools    manufacturer 


side  chair     amichair 


status 


Notes:  1. double  arrows  represent  "set_or'  relationship  (association);  2.  [x]  represent 
vectors;  3.  circles  with  a  number  represent  chair  part  number  in  Fig.  1;  4.  an  arc  betweei 
side  and  armchairs  represents  generalization;  5.  dots  below  AGV,  cell,  etc.  mean  tha 
these  objects  have  complex  structure  which  is  not  shoT\'n  in  the  diagram. 


Relationships  (R) 

Ll(chair,  AGV) 
L2(chair,  cell) 
L3(chair,  load.unload) 
D1(AGV,  ceU) 
D2(AGV,  load.unload) 
M(status,celltype) 


/*  a  chair  is  located  on  the  AGV; 

/*  a  chair  is  being  processed  by  a  cell; 

/*  a  chair  located  at  the  load.unload  station; 

/*  AGV  is  docked  at  a  cell; 

/*  AGV  is  docked  at  the  load.imload  station. 

/*  at  what  cell  type  next  operation  can  be  done 

/*(since  status  determines  op.  to  be  done  next) 


Integrity  Constraints  (IC) 

(presented  informally  here) 

Al.  If  a  chair  is  inserted  into  the  FMS  object,  then  it  must  be  related  to  either  AGV  o 
cell  or  load.unload  station  via  Ll  or  L2  or  L3  relationships. 

A2.  Only  one  chair  can  be  processed  in  a  cell  at  a  time. 


Figure  It. FMS  as  a  Complex  Object. 


struct  FMS  {  .       • , 

name        :  string; 

AGV         :  set_of  struct  {  }  /*  subobjects  of  AGV    v  '., 

load_unload  :  struct  {  }  /*  subobjects  of  load/unload 

cell.type    :  set_of  struct  { 

id  :  string; 

manufacturer    :  integer; 

tools  :  set_of  {  }■ 

cell  :  list_of  {  ....  } 

/*  cells  are  ordered  within  type  */ 

} 

chair  :  set_of  struct  { 

status  :  integer;    /*  characterizes  the  stage  of  assembly; 

/*  (what  has  been  done  already) 
paTt_l  :  . . .  ; 

part_2  :  .  .  .  ;  .  ^  ■ :, 

part_3[3]  :  ...;  ■ 

part_5  :  . .  .  ; 
union  { 

side.chair  :  struct  {  part_4  :  ...;} 

armchair    :  struct  {part_4'  :  ...;  part_6[2]  :  ...;  part_7[2]  :  ...;} 
> 
} 

/*  Relationships  */ 

LKchair,  AGV)        /*  a  chair  is  located  on  the  AGV; 

L2 (chair,  cell)       /*  a  chair  is  being  processed  by  a  cell; 

L3(chair,  load_unload)/*  a  chair  located  at  the  load_unload  station; 

D1(AGV,  cell)  /*  AGV  is  docked  at  a  cell; 

D2(AGV,  load.unload)   /*  AGV  is  docked  at  the  load.unload  station. 

M(status,cell_type)  /*  at  what  cell  type  next  operation  can  be  done 

/♦(since  status  determines  op.  to  be  done  next) 

} 

/*   Integrity  Constraints   */ 

Al:  PARENT(FMS, chair)  =J>  (3  AGV)  Ll(chair,  AGV)  V  (3  ceU)  L2(chair,cell)  V 
(3  load_unload)  L3(chair,  load_unload) 

A2:  L2(chair,cell)  =^  (V  chair')  not  L2(chair',cell) 

Figure  Ic.  Syntactic  Definition  of  Complex  Object  FMS. 


Inputs.     1.  complex  system  (CO,TR);  2.  total  order  -<  on  TR;  3.  simulation  termination  time  T. 
Outputs.     One  of  non-deterministic  states  of  the  CO  at  time  T  or  when  simulation  stops. 
Algorithm: 

HAKENULL(ACT) ; 

IHSERT«  O.e.e  >,ACT); 

t  -  -1; 

while  t  <  r  and  ACT  5^  0  do 

DELETEMIM«   t„R„op,   >.   ACT); 
while  ii  =  t  do 

if  operation  op,   is  DELETE  or  UPDATE  then 

execute  opi 
reaove  ?  froa  the   items   involved  in  the  operation; 
Evailuate   IC  lor  the  new  state  of  CO  in  3- valued  logic; 
if  evaluation  of  IC  yields  f  or  ?  then 

Stop  eiaulation  and  exit   (i.e.     abort  that  non-deterainistic  alternative); 
DELETEHIH«   t,,R,,op,   >,   ACT) 
end 
t=U; 


forall  rules  R,   in  order  based  on  -<  do 

Compute  SAT{R,,CO)  based  on  3- valued  logic; 

Select  a  non-deterministic   alternative  for  the  rule  R,   and  the   SAT  set, 
i.e.      select  tuples  from  SAT{R,,CO)  corresponding  to  this  alternative; 
Denote  the  resulting  set  DSAT{R,,CO); 
forall  o.j  e  DSAT{R,,CO)  do 

/•  a,j   is  a  tuple  of  bindings  for  all   the  variables   in  the  action  part  of  R,   */ 
find  completion  time  (,j   for  a,j    (see  text)  ; 
forall  elementary  actions  A,k    in  rule   R,   do 

bind  variables  of   A,k  using  the  binding  tuple  on,; 
this  binding  results   in  the  operation  op,,k  ; 
INSERT(<   U,,R,,op,,k   >.   ACT); 
case  op,jk  of 


IHSJIEL 


DEL_REL 


INSJ>AR 


DELJAR   : 

UPDATE   : 
end  case 
end  for 
end  for 
end  for 
end  while 
return   (CO) ; 


insert   (ai,...,an)   into  R; 

mark  (oi, . . .  ,o„)  €  iJ  with  ?. 

•here   (.ai, . . .  ,an,R)   are  pariimeters  of  INSJIEL; 

■ark  {ai,...,a„)  q  R  with  ?, 

vhere  (.ai,...,a„,R)   are  parameters  of  DELJIEL; 

insert  Ok   as  a  child  of  Oj,   vhere  Oj,Ok   are  parameters  of  INSJ'AR; 

mark  Ok,    its  entire  subtree  (nodes  and  relationships)  and  attached 

relationships  sith  ?; 

■ark  Ok,   its  entire  subtree  (nodes  and  relationships)  and  attached 

relationships  with  ?,  where  0,,0k   are  parameters  of  DELJ>AR; 

mark  the  leaf  element  of  path  with  ?,  where  path  is  the  parameter  of  UPDATE; 


Figure  2.  Simulation  Algorithm. 


Notes:  1.  rules  Rl  -  R4  form  R-nodes;  LI,  L2,  Dl,  M,  ch.stat  and  cell_type.cell  form 
P-nodes;  2.  edges  from  "celLtype.cell"  to  Rl  -  R4  are  not  shown  in  the  diagram  not  to 
clutter  the  picture;  3.  "ch.stat"  stands  for  "chair.status". 

Figure  3.  Propagation  graph  for  FMS 
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Figure  4.  Initial  state  of  maintained  relationships  for  FMS. 
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Notes:  1.  values  in  rectanguljir  boxes  next  to  maintained  relationships 
represent  actual  values  Val  (see  text);  2.  "+"  next  to  a  rule  means  that  the 
rule  matches  against  the  CO;  3.  "same"  means  that  Veil  has  not  chsLnged 
and  eqiuds  to  Val  at  the  previous  level. 


Figure  5.  Trace  DAG  for  FMS. 
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